Parallel processing of blockchain procedures

ABSTRACT

A client computer may split a process into sub-processes, send each sub-processes to a different group of peers in a blockchain network, wherein each group has at least one peer from each essential organization in the blockchain network, receive processed sub-transactions from the peers in the blockchain network, validate each sub-transaction, and validate the transaction based on the validation of all sub-transactions, wherein all sub-transaction must be valid for the transaction to be valid.

BACKGROUND

The present disclosure relates generally to the field of blockchainprocessing, and more specifically to improvements of blockchainprocessing time.

Blockchains offer immutability of data by replicating data across allnodes of a network. In order to be able to validate the blockchain,nodes generally require access to the complete history of actions. Acomplete history of actions is typically listed on the chain and isvisible for all participants.

SUMMARY

Embodiments of the present disclosure include a method, system, andcomputer program product for parallel processing of blockchainprocedures.

Some embodiments of the present disclosure can be illustrated by amethod comprising, sending, by the processor, each sub-transaction to adifferent group of peers in a blockchain network, wherein each group hasat least one peer from each essential organization in the blockchainnetwork, receiving, by the processor, processed sub-transactions fromthe peers in the blockchain network, validating each sub-transaction,and validating the transaction based on the validation of allsub-transactions, wherein all sub-transaction must be valid for thetransaction to be valid.

Some embodiments of the present disclosure can also be illustrated by asystem comprising a processor, and a memory in communication with theprocessor, the memory containing program instructions that, whenexecuted by the processor, are configured to cause the processor toperform a method, the method comprising split a transaction into two ormore sub-transactions, send each sub-transaction to a different group ofpeers in a blockchain network, wherein each group has at least one peerfrom each essential organization in the blockchain network, receiveprocessed sub-transactions from the peers in the blockchain network,validating each sub-transaction, and validating the transaction based onthe validation of all sub-transactions, wherein all sub-transaction mustbe valid for the transaction to be valid.

Some embodiments of the present disclosure can also be illustrated by acomputer program product comprising a computer readable storage mediumhaving program instructions embodied therewith, the program instructionsexecutable with a processor, in a node of a blockchain network, to causethe processors to perform a function, the function comprising splitting,by the processor, a transaction into sub-transactions, sending, by theprocessor, each sub-transaction to a different group of peers in ablockchain network, wherein each group has at least one peer from eachessential organization in the blockchain network, receiving, by theprocessor, processed sub-transactions from the peers in the blockchainnetwork, validating each sub-transaction, and validating the transactionbased on the validation of all sub-transactions, wherein allsub-transaction must be valid for the transaction to be valid.

The above summary is not intended to describe each illustratedembodiment or every implementation of the present disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings included in the present disclosure are incorporated into,and form part of, the specification. They illustrate embodiments of thepresent disclosure and, along with the description, serve to explain theprinciples of the disclosure. The drawings are only illustrative ofcertain embodiments and do not limit the disclosure.

FIG. 1 illustrates a blockchain system diagram with a parallel flow forparallel processing of blockchain procedures according to exampleembodiments.

FIG. 2 illustrates a flow diagram of parallel processing of blockchainprocedures, according to example embodiments.

FIG. 3 illustrates a network diagram of a system including a database,according to an example embodiment.

FIG. 4A illustrates an example blockchain architecture configuration,according to example embodiments.

FIG. 4B illustrates a blockchain transactional flow, according toexample embodiments.

FIG. 5A illustrates a permissioned network, according to exampleembodiments.

FIG. 5B illustrates another permissioned network, according to exampleembodiments.

FIG. 5C illustrates a permissionless network, according to exampleembodiments.

FIG. 6A illustrates a process for a new block being added to adistributed ledger, according to example embodiments.

FIG. 6B illustrates contents of a new data block, according to exampleembodiments.

FIG. 6C illustrates a blockchain for digital content, according toexample embodiments.

FIG. 6D illustrates a block which may represent the structure of blocksin the blockchain, according to example embodiments.

FIG. 7A illustrates a cloud computing environment, in accordance withembodiments of the present disclosure.

FIG. 7B illustrates abstraction model layers, in accordance withembodiments of the present disclosure.

FIG. 8 illustrates a high-level block diagram of an example computersystem that may be used in implementing one or more of the methods,tools, and modules, and any related functions, described herein, inaccordance with embodiments of the present disclosure.

While the embodiments described herein are amenable to variousmodifications and alternative forms, specifics thereof have been shownby way of example in the drawings and will be described in detail. Itshould be understood, however, that the particular embodiments describedare not to be taken in a limiting sense. On the contrary, the intentionis to cover all modifications, equivalents, and alternatives fallingwithin the spirit and scope of the disclosure.

DETAILED DESCRIPTION

Aspects of the present disclosure relate generally to the field ofblockchain processing, and more specifically to improvements ofblockchain processing time.

It will be readily understood that the instant components, as generallydescribed and illustrated in the figures herein, may be arranged anddesigned in a wide variety of different configurations. Accordingly, thefollowing detailed description of the embodiments of at least one of amethod, apparatus, non-transitory computer readable medium and system,as represented in the attached figures, is not intended to limit thescope of the application as claimed but is merely representative ofselected embodiments.

The instant features, structures, or characteristics as describedthroughout this specification may be combined or removed in any suitablemanner in one or more embodiments. For example, the usage of the phrases“example embodiments,” “some embodiments,” or other similar language,throughout this specification refers to the fact that a particularfeature, structure, or characteristic described in connection with theembodiment may be included in at least one embodiment. Accordingly,appearances of the phrases “example embodiments,” “in some embodiments,”“in other embodiments,” or other similar language, throughout thisspecification do not necessarily all refer to the same group ofembodiments, and the described features, structures, or characteristicsmay be combined or removed in any suitable manner in one or moreembodiments. Further, in the FIGS., any connection between elements canpermit one-way and/or two-way communication even if the depictedconnection is a one-way or two-way arrow. Also, any device depicted inthe drawings can be a different device. For example, if a mobile deviceis shown sending information, a wired device could also be used to sendthe information.

In addition, while the term “message” may have been used in thedescription of embodiments, the application may be applied to many typesof networks and data. Furthermore, while certain types of connections,messages, and signaling may be depicted in exemplary embodiments, theapplication is not limited to a certain type of connection, message, andsignaling.

Detailed herein is a method, system, and computer program product thatutilize blockchain (specifically, Hyperledger Fabric) channels, andsmart contracts that implement logic based on a non-interactive zeroknowledge proof.

In some embodiments, the method, system, and/or computer program productutilize a decentralized database (such as a blockchain) that is adistributed storage system, which includes multiple nodes thatcommunicate with each other. The decentralized database includes anappend-only immutable data structure resembling a distributed ledgercapable of maintaining records between mutually untrusted parties. Theuntrusted parties are referred to herein as peers or peer nodes. Eachpeer maintains a copy of the database records and no single peer canmodify the database records without a consensus being reached among thedistributed peers. For example, the peers may execute a consensusprotocol to validate blockchain storage transactions, group the storagetransactions into blocks, and build a hash chain over the blocks. Thisprocess forms the ledger by ordering the storage transactions, as isnecessary, for consistency.

In various embodiments, a permissioned and/or a permission-lessblockchain can be used. In a public or permission-less blockchain,anyone can participate without a specific identity (e.g., retaininganonymity). Public blockchains can involve native cryptocurrency and useconsensus based on various protocols such as Proof of Work. On the otherhand, a permissioned blockchain database provides secure interactionsamong a group of entities which share a common goal, but which do notfully trust one another, such as businesses that exchange funds, goods,information, and the like.

Further, in some embodiments, the method, system, and/or computerprogram product can utilize a blockchain that operates arbitrary,programmable logic, tailored to a decentralized storage scheme andreferred to as “smart contracts” or “chaincodes.” In some cases,specialized chaincodes may exist for management functions and parameterswhich are referred to as system chaincode. The method, system, and/orcomputer program product can further utilize smart contracts that aretrusted distributed applications which leverage tamper-proof propertiesof the blockchain database and an underlying agreement between nodes,which is referred to as an endorsement or endorsement policy. Blockchaintransactions associated with this application can be “endorsed” beforebeing committed to the blockchain while transactions, which are notendorsed, are disregarded.

An endorsement policy allows chaincode to specify endorsers for atransaction in the form of a set of peer nodes that are necessary forendorsement. When a client sends the transaction to the peers specifiedin the endorsement policy, the transaction is executed to validate thetransaction. After validation, the transactions enter an ordering phasein which a consensus protocol is used to produce an ordered sequence ofendorsed transactions grouped into blocks.

In some embodiments, the method, system, and/or computer program productcan utilize nodes that are the communication entities of the blockchainsystem. A “node” may perform a logical function in the sense thatmultiple nodes of different types can run on the same physical server.Nodes are grouped in trust domains and are associated with logicalentities that control them in various ways. Nodes may include differenttypes, such as a client or submitting-client node which submits atransaction-invocation to an endorser (e.g., peer), and broadcaststransaction-proposals to an ordering service (e.g., ordering node).

Another type of node is a peer node which can receive client submittedtransactions, commit the transactions and maintain a state and a copy ofthe ledger of blockchain transactions. Peers can also have the role ofan endorser, although it is not a requirement. An ordering-service-node,block generator, or orderer is a node running the communication servicefor all nodes, and which implements a delivery guarantee, such as abroadcast to each of the peer nodes in the system whencommitting/confirming transactions and modifying a world state of theblockchain, which is another name for the initial blockchain transactionwhich normally includes control and setup information.

In some embodiments, the method, system, and/or computer program productcan utilize a ledger that is a sequenced, tamper-resistant record of allstate transitions of a blockchain. State transitions may result fromchaincode invocations (e.g., transactions) submitted by participatingparties (e.g., client nodes, ordering nodes, endorser nodes, peer nodes,etc.). Each participating party (such as a peer node) can maintain acopy of the ledger. A transaction may result in a set of asset key-valuepairs being committed to the ledger as one or more operands, such ascreates, updates, deletes, and the like. The ledger includes ablockchain (also referred to as a chain) which is used to store animmutable, sequenced record in blocks. The ledger also includes a statedatabase which maintains a current state of the blockchain.

In some embodiments, the method, system, and/or computer program productdescribed herein can utilize a chain that is a transaction log that isstructured as hash-linked blocks, and each block contains a sequence ofN transactions where N is equal to or greater than one. The block headerincludes a hash of the block's transactions, as well as a hash of theprior block's header. In this way, all transactions on the ledger may besequenced and cryptographically linked together. Accordingly, it is notpossible to tamper with the ledger data without breaking the hash links.A hash of a most recently added blockchain block represents everytransaction on the chain that has come before it, making it possible toensure that all peer nodes are in a consistent and trusted state. Thechain may be stored on a peer node file system (e.g., local, attachedstorage, cloud, etc.), efficiently supporting the append-only nature ofthe blockchain workload.

The current state of the immutable ledger represents the latest valuesfor all keys that are included in the chain transaction log. Since thecurrent state represents the latest key values known to a channel, it issometimes referred to as a world state. Chaincode invocations executetransactions against the current state data of the ledger. To make thesechaincode interactions efficient, the latest values of the keys may bestored in a state database. The state database may be simply an indexedview into the chain's transaction log, it can therefore be regeneratedfrom the chain at any time. The state database may automatically berecovered (or generated if needed) upon peer node startup, and beforetransactions are accepted.

Some benefits of the instant solutions described and depicted hereininclude a method, system, and computer program product for parallelprocessing of blockchain procedures. The exemplary embodiments solve theissues of reliability, time, and trust by extending features of adatabase such as immutability, digital signatures, and being a singlesource of truth. The exemplary embodiments provide a solution for excessprocessing of blockchain procedures (e.g. transactions) on blockchain.

Blockchain is different from a traditional database in that blockchainis not a central storage, but rather a decentralized, immutable, andsecure storage, where nodes may share in changes to records in thestorage. Some properties that are inherent in blockchain and which helpimplement the blockchain include, but are not limited to, an immutableledger, smart contracts, security, privacy, decentralization, consensus,endorsement, accessibility, and the like, which are further describedherein. According to various aspects, the system described herein isimplemented due to immutable accountability, security, privacy,permitted decentralization, availability of smart contracts,endorsements and accessibility that are inherent and unique toblockchain.

In particular, the blockchain ledger data is immutable and that providesfor an efficient method for parallel processing of blockchainprocedures. Also, use of the encryption in the blockchain providessecurity and builds trust. The smart contract manages the state of theasset to complete the life-cycle. The example blockchains are permissiondecentralized. Thus, each end user may have its own ledger copy toaccess. Multiple organizations (and peers) may be on-boarded on theblockchain network. The key organizations may serve as endorsing peersto validate the smart contract execution results, read-set andwrite-set. In other words, the blockchain inherent features provide forefficient implementation of processing a private transaction in ablockchain network.

One of the benefits of the example embodiments is that it improves thefunctionality of a computing system by implementing a method forprocessing a private transaction in a blockchain network. Through theblockchain system described herein, a computing system (or a processorin the computing system) can perform functionality for privatetransaction processing utilizing blockchain networks by providing accessto capabilities such as distributed ledger, peers, encryptiontechnologies, MSP, event handling, etc. Also, the blockchain enablessystems to create a business network and make any users or organizationson-board for participation. As such, the blockchain is not just adatabase. The blockchain comes with capabilities to create a network ofusers and on-board/off-board organizations to collaborate and executeservice processes in the form of smart contracts.

The example embodiments provide numerous benefits over a traditionaldatabase. For example, through the blockchain the embodiments providefor immutable accountability, security, privacy, permitteddecentralization, availability of smart contracts, endorsements andaccessibility that are inherent and unique to the blockchain.

A procedure (e.g., a transaction) is usually executed by multiple peersin a blockchain. Each peer executes the same transaction on the samedata. Multiple peers are required to ensure the reliability oftransaction execution results by cross checking each other. Theexecution of a transaction is considered successful when all theendorsing peers executing this transaction reach a consensus. The resultis appropriately signed by each peer and matched to other peers.

However, this execution model can be resource consuming, especially whena transaction needs to be endorsed by a large number of peers and/or atransaction needs to work on a large amount of data. Take, for example,a transaction of “which day in the past 3 years had the most itemsshipped”? In a traditional system, each peer needs to execute the wholetransaction, which takes a significant time to finish when thetransaction is expensive. Expensive here means that the transaction mayrequire the utilization of a significant amount of resources. Forexample, a transaction that requires processing of large data sets maybe considered expensive by an organization. This issue is exacerbatedwhen a blockchain has to process multiple transactions that have to beexecuted by multiple individual peers.

This leads to the issue of how to improve the execution efficiency ofsuch expensive transactions, while still preserving the reliability suchthat the execution behavior of normal (non-expensive) transactions isnot affected. In some embodiments, a method is provided for dividingtransactions into sub-transactions and sending each sub-transaction to adifferent group of peers.

In some embodiments, by processing the sub-transactions by groups ofpeers rather than the blockchain as a whole, the transactions (fromwhich the sub-transactions are derived) maintain the properties that areinherent in blockchain and not present in a traditional database, whilestreamlining the processing of the transactions. Some of the benefits ofa blockchain that are not part of a traditional database but areinherent to blockchain include, but are not limited to, an immutableledger, smart contracts, security, privacy, decentralization, consensus,endorsement, and accessibility. More details of these benefits and howthey are realized in blockchain are discussed above. According tovarious aspects, the system described herein has benefits over atraditional system due to immutable accountability, security, privacy,permitted decentralization, availability of smart contracts,endorsements and accessibility that are inherent and unique toblockchain. In some embodiments of the present disclosures, thesebenefits of the overall blockchain system may be applied to thesub-transactions on an individual basis. In other words, the blockchaininherent features provide unique benefits for efficient implementationof parallel processing that may not be present in a traditional systemwhere a job or process may be split up for two or more processors tocomplete tangentially.

Referring now to FIG. 1 , illustrated is an example system 100 forparallel processing of blockchain procedures, in accordance withembodiments of the present disclosure.

In some embodiments, client 105 may divide a transaction (TX) into twoor more sub-transactions. As depicted, client 105 divides transaction110 into three sub-transactions (STX) 112, 114, and 116. For example,Client 105 may divide the transaction:

-   -   Transaction (TX 110): which day in year 2017-2019 had the most        items shipped? (tx_id:1, op:max)        into three sub-transactions:    -   Sub-transactions (STX 112): which day in year 2017 had the most        items shipped? (tx_id:1, stx_id:1, total:3, group 1)    -   Sub-transactions (STX 114): which day in year 2018 had the most        items shipped? (tx_id:1, stx_id:2, total:3, group 2)    -   Sub-transactions (STX 116): which day in year 2019 had the most        items shipped? (tx_id:1, stx_id:3, total:3, group 3).        In some embodiments, the sub-transactions may have metadata        regarding the transaction, and the sub-transactions such as a        transaction identification (id), a sub-transaction id, a        designated peer group (see below), a total number of        sub-transactions, etc. For example, the metadata for STX 112 may        be (tx_id:1, stx_id:1, total:3, group 1) and the metadata for        STX 114 may be (tx_id:1, stx_id:2, total:3, group 2), where        tx_id is the transaction id number, stx_id is the        sub-transaction id number, total is the total number of        sub-transactions, and group is the group of peers that the        client is sending the sub-transaction to. Other information and        formats are possible for the metadata.

In some embodiments, client 105 may direct each sub-transaction to oneor more groups 170, 172, or 174. For example, STX 116 may be sent togroup 170, STX 114 may be sent to group 172, and STX 112 may be sent togroup 174. In some embodiments, each group may consist of one or morepeers of network peers 150. For example, group 170 may consist of peers151, 154, and 157. Group 172 may consist of peers 152, 155, and 158.Group 174 may consist of peers 153, 156, and 159. Three groups are givenas an example, some embodiments may have more groups, and some may havefewer. Likewise, each group may consist of more or fewer peers. In someembodiments, each sub-transaction may be complete before it is sent tothe peers. For example, if a sub-transaction reads “which day in year2019 had the most items shipped?” and all of the shipping data for 2019has not been reported yet, the sub-transaction is not complete and thepeers cannot endorse the sub-transaction until it is complete. Thus, thesub-transaction may be held until the data for 2019 has been reported.

In some embodiments, the sub transactions may provide additionalinformation that may be used for processing the sub transactions intotransactions. For example, if the answer to the sub-transaction in theprevious example is simply, May 31, 2019, the system may not be able tocompare this answer to the answer for other years since the number ofitems shipped on those days is not known. Therefore, the answer may alsoinclude a number of items shipped on May 31, 2019, so a comparison maybe made to the days that had the most items shipped for other years. Insome embodiments, the additional information is available on the ledger,so it may not need to be included with the answer. For example, thenumber of items shipped on May 31, 2019 is available on the ledger so ablock generator combining the sub-transactions may look up the number ofitems shipped on May 31, 2019 when comparing it to the answer for otheryears.

In some embodiments, each group may have one or more nodes belonging toone or more organizations (e.g., Org A 160, Org B 163, and Org C 166).In some embodiments, each group may be required to have at least onenode from each organization that is a part of the system 100. In someembodiments, each group may be required to have at least one node fromeach organization that is deemed essential. In some embodiments, system100 may have rules dictating what an essential organization is. Forexample, organizations that were onboarded when system 100 was initiatedmay be deemed essential. In other embodiments, client 105 may dictatewhat an essential organization is. For example, if client 105, Org B163, and Org C 166 are all associated with the same company, Org B 163and Org C 166 may be deemed essential.

Each peer may process and validate the sub-transactions in a similarmanner to a regular transaction. See FIG. 4A for detail on processingand endorsement. Following the example from above, STX 116 may produce aresult of <9/2/2017, 2000> (i.e., Sep. 2, 2017 had the most itemsshipped for the year, 2000 items). Similarly, STX 114 may produce theresult <9/8/2018, 4000>, and STX 112 may produce the result <11/20/2019,3000>.

In some embodiments, after each sub-transaction is endorsed and orprocessed by the peers, it may be sent back to the client, shown byarrows 122. If the transaction is a query, the process may end. A queryis a transaction that may not be recorded as a block on the distributedledger. If the transaction is to be recorded on the blockchain then thesub-transactions may be forwarded on to block generator 180 (e.g., anordering service). In some embodiments, the sub-transactions may becombined into a single transaction by the client. In some embodiments,the sub-transactions may be forwarded (depicted by arrows 124) to theblock generator for organizing them into a block as shown by the arrows224. In some embodiments, the block generator may maintain a queue forsub-transactions, and organize them into block(s) only when all therelated sub-transactions have arrived. Following the example from above,the result of STX 116 (e.g., <9/2/2017, 2000>) may be compared to theresults of STX 114 (e.g., <9/8/2018, 4000>), and STX 112 (e.g.,<11/20/2019, 3000>) to determine a final result of <9/8/2018, 4000>since this date had the most items shipped from any of the datesprovided in the results of the sub-transactions.

In some embodiments, the sub-transactions (ordered into blocks) may besent to the blockchain network for validation and recordation, shown byarrow 126. In some embodiments, each sub-transaction may be validated ina similar manner to regular transactions, but if any of thesub-transactions are invalidated, the transaction may be invalidated.For example, if STX 116 and STX 114 are validated, but STX 112 isinvalidated, then TX 110 may be invalidated. See FIGS. 4A, 4B, and 5Cfor details on validation in a blockchain network.

Referring now to FIG. 2 , illustrated is an example method 200 forparallel processing of blockchain procedures, in accordance withembodiments of the present disclosure.

Method 200 begins with operation 202, where a client divides atransaction into sub-transactions. In some embodiments, a client is acomputer that is connected to a blockchain network, able to submittransactions to a node on a blockchain network, and/or a node on theblockchain network. In some embodiments, a transaction is a process thatmay be submitted to the nodes of a blockchain network. Transactions thatare not recorded on the blockchain network are referred to as queriesherein. See FIG. 4B for more details on queries.

In some embodiments the dividing may depend on the number of groupsavailable. For example, if a blockchain network has three designatedgroups then the client may split a transaction into 3 groups. In someembodiments, a cost balance may be used to determine how manysub-transactions a transaction should be split into. For example, if atransaction takes 10 seconds to process, it may be determined thatsplitting a transaction into 2 sub-transactions may lead to a processingtime of 6 seconds for a single peer, and splitting a transaction into 3sub-transactions may lead to a processing time of 5 seconds. It may bedetermined that splitting the transaction into 3 sub-transactions is notwarranted over splitting the transaction into 2 sub-transactions sinceit only reduces the processing time by one second. Processing time isused for explanation purposes only, other metrics for measuring the costof transactions and sub-transactions may be used.

One of the benefits of splitting a transaction into sub-transactions isthe decreased processing time for each individual peer. It is expectedthat some transactions may not warrant splitting. For example, ifprocessing a transaction may take 10 seconds for an individual peer butsplitting the transaction into multiple sub-transactions may only reducethe processing time by 1 second, it may be determined that the benefitof reducing the processing time by 1 second does not justify splittingand the splitting of the transaction into sub-transactions may not beperformed. Therefore, a processor (e.g., the client) may perform a costanalysis of the splitting. The cost analysis may use a threshold number,such as a threshold savings (e.g., processing time savings, processingpower savings, or some other metric). Following the example from above,the threshold might be a savings of 40%, where a splitting a transactioninto multiple sub-transactions may have to realize a savings more than40% of the processing time before it was performed.

In some embodiments, the threshold, or a similar threshold, may also beused to determine how many sub-transactions to split a transaction into.For example, splitting a 10 second transaction into 4 sub-transactionsthat each take 5 seconds may result in a 50% savings in processing time,exceeding the 40% threshold. However, splitting the transaction into 5sub-transactions that take 4 seconds of processing time may result in a20% savings over the 4 sub-transaction group, which does not exceed thethreshold. Thus, the transaction may be split into 4 sub-transactions.In some embodiments, when the processor determines that a result of thecost analysis does not exceed a threshold the processor may halt thesplitting, and/or elect to send the transaction for processing insteadof the sub-transactions based on a determination that the cost analysisexceeds the threshold.

Method 200 continues with operation 204 where the client may submit thesub-transactions to the blockchain network. As stated above, in someembodiments, each transaction may be submitted to a different group ofpeers. In some embodiments, each group may be comprised of anapproximately equivalent group of peers. For example, a first and secondgroup of peers may each be comprised of 100 peers, and a third group maybe comprised of 99 peers. In some embodiments, each group may have oneor more member nodes from one or more organizations that are deemedessential. As stated above, an essential organization may be determinedby one or more rules of the blockchain network or by the client. Forexample, the client or the blockchain network may deem all organizationsthat own 10% or more of the peers in the network an essentialorganization. In some embodiments, all organizations that are part ofthe blockchain network may be deemed essential.

In operation 206 the processing of the sub-transactions may include thepeers endorsing the sub-transactions. In some embodiments, the sameendorsement policy is applied to all sub-transactions that belong to thesame transaction. An endorsement policy is a condition on what endorsesa transaction. Blockchain peers have a pre-specified set of endorsementpolicies, which are referenced by a deploy transaction that installsspecific chaincode. Endorsement policies can be parametrized, and theseparameters can be specified by a deploy transaction. See FIG. 4A fordetail on processing and endorsement in the peers. Following an examplefrom FIG. 1 , STX 116, 114, and 112 may all have the same endorsementpolicy.

In operation 208, after executing the sub-transactions, the peers maysend the results back to the client. For example, each peer may sendback an endorsement (or non-endorsement) and/or a result of thesub-transaction the peer was responsible for. In some embodiments, ifmethod 200 were performed on a query, it may end after 208. Queryresults are not recorded on the blockchain and thus do not need toproceed to the block generator.

In operation 210 the client may inspect/verify the endorsement policy ansend the endorsed sub-transactions to the block generator. For example,the client may check the endorsement policy to ensure that the correctallotment of the specified peers have signed the results andauthenticated the signatures against the transaction payload. Moredetails on a client inspecting/verifying the endorsement policy aregiven in FIG. 4B, specifically 492. If the transaction is to be recordedon the blockchain, then the sub-transactions may be forwarded on to ablock generator. In some embodiments, the sub-transactions may becombined into a single transaction by the client. In some embodiments,the sub-transactions may be forwarded to the block generator fororganizing them into a block. In some embodiments, the block generatormay maintain a queue for sub-transactions and organize them intoblock(s) only when all the related sub-transactions have arrived.

In operation 212, the block generator organizes the sub-transactionsinto the block(s) and deliver the block(s) to the peers. In someembodiments, the order may maintain a queue of sub-transactions anddelay organizing the sub-transactions into block(s) until allsub-transactions for a particular transaction have been received. Forexample, the queue may have a list of multiple sub-transactions formultiple transactions from multiple clients. If the block generatorstarted organizing sub-transactions for a particular transaction beforeall the sub-transactions for that particular transaction had beenreceived, the block generator may have to halt the organization and waitfor the rest of the sub-transactions for that particular transactionbefore the block generator may finish.

In some embodiments, the peers may aggregate the sub-transactions in thevalidation phase, and update the World State, if necessary, by using theaggregated result. In some embodiments, the aggregation results may bederived from comparing the results for the three sub transactions.Following the example from FIG. 1 , where the results for the threesub-transactions were <9/2/2017, 2000><9/8/2018, 4000>, <11/20/2019,3000>, the three sub-transactions may be aggregated to find the finalresult of <9/8/2018, 4000> for the transaction “which day in year2017-2019 had the most items shipped?” In this case, the results fromeach year may be compared to each other to determine which one of theresults from the three sub-transactions had the most units shipped. Onthe date Sep. 8, 2018 4000 items were shipped which is more than thenumber of items shipped on listed in the answers for 2017 and 2019. Insome embodiments, the aggregation may be from combining the results ofthe sub-transactions. For example, modifying the previous example, for atransaction of “what was the average number of items shipped per day in2017 and 2018.” The transaction may be split into sub-transactions of“what was the average number of items shipped per day in 2017” and “whatwas the average number of items shipped per day in 2018.” If thesub-transaction results came back as an average of 1000 for 2017 and2000 for 2018 then the results could be aggregated to obtain on overallaverage of 1500 (e.g. the average of 1000 and 2000) for the averagenumber of items shipped per day in 2017 and 2018. Other methods ofaggregation may be possible.

Speaking to validation, in some embodiments, each sub-transaction may bevalidated in a similar way as normal transactions. However, if onesub-transaction is invalidated, then the original transaction thesub-transactions were derived from may be invalidated since thetransaction as a whole cannot be validated. Following the previousexample, if the sub-transaction result <9/8/2018, 4000> was invalidated,then the other two sub-transactions may not be aggregated to give anaccurate result for the years 2017-2019. Without validated data for 2018an aggregated result (e.g., the result for the original transaction)cannot be determined. See FIGS. 4A, 4B, and 5C for details on validationin a blockchain network. In some embodiments, the validation of atransaction may be based on the validation of all sub-transactionsderived from the transaction.

FIG. 3 illustrates a logic network diagram for smart data annotation inblockchain networks, according to example embodiments.

Referring to FIG. 3 , the example network 300 includes a client node 302connected to other blockchain (BC) nodes 305 representing document-ownerorganizations. The client node 302 may be connected to a blockchain 306that has a ledger 308 for storing data to be shared among the nodes 305.While this example describes in detail only one client node 302,multiple such nodes may be connected to the blockchain 306. It should beunderstood that the client node 302 may include additional componentsand that some of the components described herein may be removed and/ormodified without departing from a scope of the client node 302 disclosedherein. The client node 302 may be a computing device or a servercomputer, or the like, and may include a processor 304, which may be asemiconductor-based microprocessor, a central processing unit (CPU), anapplication specific integrated circuit (ASIC), a field-programmablegate array (FPGA), and/or another hardware device. Although a singleprocessor 304 is depicted, it should be understood that the client node302 may include multiple processors, multiple cores, or the like,without departing from the scope of the client node 302 system. Adistributed file storage 350 may be accessible to processor node 302 andother BC nodes 305. The distributed file storage may be used to storedocuments identified in ledger (distributed file storage) 350.

The client node 302 may also include a non-transitory computer readablemedium 312 that may have stored thereon machine-readable instructionsexecutable by the processor 304. Examples of the machine-readableinstructions are shown as 314-320 and are further discussed below.Examples of the non-transitory computer readable medium 312 may includean electronic, magnetic, optical, or other physical storage device thatcontains or stores executable instructions. For example, thenon-transitory computer readable medium 312 may be a Random Accessmemory (RAM), an Electrically Erasable Programmable Read-Only Memory(EEPROM), a hard disk, an optical disc, or other type of storage device.

The processor 304 may execute the machine-readable instructions 314 toreceive a transaction. As discussed above, the blockchain ledger 308 maystore data to be shared among the nodes 305. The blockchain 306 networkmay be configured to use one or more smart contracts that managetransactions for multiple participating nodes. Documents linked to theannotation information may be stored in distributed file storage 350.The processor 304 may execute the machine-readable instructions 314 todivide a transaction into sub-transactions. The processor 304 mayexecute the machine-readable instructions 316 to submit thesub-transactions to the blockchain network. The processor 304 mayexecute the machine-readable instructions 318 to receive the executionresults from the peers.

FIG. 4A illustrates a blockchain architecture configuration 400,according to example embodiments. Referring to FIG. 4A, the blockchainarchitecture 400 may include certain blockchain elements, for example, agroup of blockchain nodes 402. The blockchain nodes 402 may include oneor more peer nodes 404-410 (these four nodes are depicted by exampleonly). These nodes participate in a number of activities, such asblockchain transaction addition and validation process (consensus). Oneor more of the blockchain nodes 404-410 may endorse transactions basedon endorsement policy and may provide an ordering service for allblockchain nodes in the architecture 400. A blockchain node may initiatea blockchain authentication and seek to write to a blockchain immutableledger stored in blockchain layer 416, a copy of which may also bestored on the underpinning physical infrastructure 414. The blockchainconfiguration may include one or more applications 424 which are linkedto application programming interfaces (APIs) 422 to access and executestored program/application code 420 (e.g., chaincode, smart contracts,etc.) which can be created according to a customized configurationsought by participants and can maintain their own state, control theirown assets, and receive external information. This can be deployed as atransaction and installed, via appending to the distributed ledger, onall blockchain nodes 404-410.

The blockchain base or platform 412 may include various layers ofblockchain data, services (e.g., cryptographic trust services, virtualexecution environment, etc.), and underpinning physical computerinfrastructure that may be used to receive and store new transactionsand provide access to auditors which are seeking to access data entries.The blockchain layer 416 may expose an interface that provides access tothe virtual execution environment necessary to process the program codeand engage the physical infrastructure 414. Cryptographic trust services418 may be used to verify transactions such as asset exchangetransactions and keep information private.

The blockchain architecture configuration of FIG. 4A may process andexecute program/application code 420 via one or more interfaces exposed,and services provided, by blockchain platform 412. The code 420 maycontrol blockchain assets. For example, the code 420 can store andtransfer data, and may be executed by nodes 404-410 in the form of asmart contract and associated chaincode with conditions or other codeelements subject to its execution. As a non-limiting example, smartcontracts may be created to execute reminders, updates, and/or othernotifications subject to the changes, updates, etc. The smart contractscan themselves be used to identify rules associated with authorizationand access requirements and usage of the ledger. For example, thedocument attribute(s) information 426 may be processed by one or moreprocessing entities (e.g., virtual machines) included in the blockchainlayer 416. The result 428 may include a plurality of linked shareddocuments. The physical infrastructure 414 may be utilized to retrieveany of the data or information described herein.

A smart contract may be created via a high-level application andprogramming language, and then written to a block in the blockchain. Thesmart contract may include executable code which is registered, stored,and/or replicated with a blockchain (e.g., distributed network ofblockchain peers). A transaction is an execution of the smart contractcode which can be performed in response to conditions associated withthe smart contract being satisfied. The executing of the smart contractmay trigger a trusted modification(s) to a state of a digital blockchainledger. The modification(s) to the blockchain ledger caused by the smartcontract execution may be automatically replicated throughout thedistributed network of blockchain peers through one or more consensusprotocols.

The smart contract may write data to the blockchain in the format ofkey-value pairs. Furthermore, the smart contract code can read thevalues stored in a blockchain and use them in application operations.The smart contract code can write the output of various logic operationsinto the blockchain. The code may be used to create a temporary datastructure in a virtual machine or other computing platform. Data writtento the blockchain can be public and/or can be encrypted and maintainedas private. The temporary data that is used/generated by the smartcontract is held in memory by the supplied execution environment, thendeleted once the data needed for the blockchain is identified.

A chaincode may include the code interpretation of a smart contract,with additional features. As described herein, the chaincode may beprogram code deployed on a computing network, where it is executed andvalidated by chain validators together during a consensus process. Thechaincode receives a hash and retrieves from the blockchain a hashassociated with the data template created by use of a previously storedfeature extractor. If the hashes of the hash identifier and the hashcreated from the stored identifier template data match, then thechaincode sends an authorization key to the requested service. Thechaincode may write to the blockchain data associated with thecryptographic details.

FIG. 4B illustrates an example of a blockchain transactional flow 450between nodes of the blockchain in accordance with an exampleembodiment. Referring to FIG. 4B a general description of transactionalflow 450 will be given followed by a more specific example. Thetransaction flow may include a transaction proposal 491 sent by anapplication client node 460 to an endorsing peer node 481. The endorsingpeer 481 may verify the client signature and execute a chaincodefunction to initiate the transaction. The output may include thechaincode results, a set of key/value versions that were read in thechaincode (read set), and the set of keys/values that were written inchaincode (write set). The proposal response 492 is sent back to theclient 460 along with an endorsement signature, if approved. The client460 assembles the endorsements into a transaction payload 493 andbroadcasts it to an ordering service node 484. The ordering service node484 then delivers ordered transactions as blocks to all peers 481-483 ona channel. Before committal to the blockchain, each peer 481-483 mayvalidate the transaction. For example, the peers may check theendorsement policy to ensure that the correct allotment of the specifiedpeers have signed the results and authenticated the signatures againstthe transaction payload 493. In some embodiments, one or more of thepeers may be the manager nodes.

A more specific description of transactional flow 450 can be understoodwith a more specific example. To begin, the client node 460 initiatesthe transaction 491 by constructing and sending a request to the peernode 481, which is an endorser. The client 460 may include anapplication leveraging a supported software development kit (SDK), whichutilizes an available API to generate a transaction proposal. Theproposal is a request to invoke a chaincode function so that data can beread and/or written to the ledger (i.e., write new key value pairs forthe assets). The SDK may serve as a shim to package the transactionproposal into a properly architected format (e.g., protocol buffer overa remote procedure call (RPC)) and take the client's cryptographiccredentials to produce a unique signature for the transaction proposal.

In response, the endorsing peer node 481 may verify (a) that thetransaction proposal is well formed, (b) the transaction has not beensubmitted already in the past (replay-attack protection), (c) thesignature is valid, and (d) that the submitter (client 460, in theexample) is properly authorized to perform the proposed operation onthat channel. The endorsing peer node 481 may take the transactionproposal inputs as arguments to the invoked chaincode function. Thechaincode is then executed against a current state database to producetransaction results including a response value, read set, and write set.However, no updates are made to the ledger at this point. In 492, theset of values, along with the endorsing peer node's 481 signature ispassed back as a proposal response 492 to the SDK of the client 460which parses the payload for the application to consume.

In response, the application of the client 460 inspects/verifies theendorsing peers' signatures and compares the proposal responses todetermine if the proposal response is the same. If the chaincode onlyqueried the ledger, the application may inspect the query response andmay typically not submit the transaction to the ordering service node484. If the client application intends to submit the transaction to theordering node service 484 to update the ledger, the applicationdetermines if the specified endorsement policy has been fulfilled beforesubmitting (i.e., did all peer nodes necessary for the transactionendorse the transaction). Here, the client may include only one ofmultiple parties to the transaction. In this case, each client may havetheir own endorsing node, and each endorsing node may need to endorsethe transaction. The architecture is such that even if an applicationselects not to inspect responses or otherwise forwards an unendorsedtransaction, the endorsement policy may still be enforced by peers andupheld at the commit validation phase.

After successful inspection, the client 460 assembles endorsements intoa transaction 493 and broadcasts the transaction proposal and responsewithin a transaction message to the ordering node 484. The transactionmay contain the read/write sets, the endorsing peers' signatures and achannel ID. The ordering node 484 does not need to inspect the entirecontent of a transaction in order to perform its operation. Instead, theordering node 484 may simply receive transactions from all channels inthe network, order them chronologically by channel, and create blocks oftransactions per channel.

The blocks of the transaction are delivered from the ordering node 484to all peer nodes 481-483 on the channel. The transactions 494 withinthe block are validated to ensure any endorsement policy is fulfilledand to ensure that there have been no changes to ledger state for readset variables since the read set was generated by the transactionexecution. Transactions in the block are tagged as being valid orinvalid. Furthermore, in step 495 each peer node 481-483 appends theblock to the channel's chain, and for each valid transaction the writesets are committed to current state database. An event is emitted tonotify the client application that the transaction (invocation) has beenimmutably appended to the chain, as well as to notify whether thetransaction was validated or invalidated.

FIG. 5A illustrates an example of a permissioned blockchain network 500,which features a distributed, decentralized peer-to-peer architecture.In this example, a blockchain user 502 may initiate a transaction to thepermissioned blockchain 504. In this example, the transaction can be adeploy, invoke, or query, and may be issued through a client-sideapplication leveraging an SDK, directly through an API, etc. Networksmay provide access to a regulator 506, such as an auditor. A blockchainnetwork operator 508 manages member permissions, such as enrolling theregulator 506 as an “auditor” and the blockchain user 502 as a “client.”An auditor may be restricted only to querying the ledger whereas aclient may be authorized to deploy, invoke, and query certain types ofchaincode.

A blockchain developer 510 can write chaincode and client-sideapplications. The blockchain developer 510 can deploy chaincode directlyto the network through an interface. To include credentials from atraditional data source 512 in chaincode, the developer 510 may use anout-of-band connection to access the data. In this example, theblockchain user 502 connects to the permissioned blockchain 504 throughone of peer nodes 514 (referring to any one of nodes 514 a-e). Beforeproceeding with any transactions, the peer node 514 (e.g., node 514 a)retrieves the user's enrollment and transaction certificates from acertificate authority 516, which manages user roles and permissions. Insome cases, blockchain users must possess these digital certificates inorder to transact on the permissioned blockchain 504. Meanwhile, a userattempting to utilize chaincode may be required to verify theircredentials on the traditional data source 512. To confirm the user'sauthorization, chaincode can use an out-of-band connection to this datathrough a traditional processing platform 518.

FIG. 5B illustrates another example of a permissioned blockchain network520, which features a distributed, decentralized peer-to-peerarchitecture. In this example, a blockchain user 522 may submit atransaction to the permissioned blockchain 524. In this example, thetransaction can be a deploy, invoke, or query, and may be issued througha client-side application leveraging an SDK, directly through an API,etc. Networks may provide access to a regulator 526, such as an auditor.A blockchain network operator 528 manages member permissions, such asenrolling the regulator 526 as an “auditor” and the blockchain user 522as a “client.” An auditor may be restricted to only querying the ledgerwhereas a client may be authorized to deploy, invoke, and query certaintypes of chaincode.

A blockchain developer 530 writes chaincode and client-sideapplications. The blockchain developer 530 can deploy chaincode directlyto the network through an interface. To include credentials from atraditional data source 532 in chaincode, the developer 530 may use anout-of-band connection to access the data. In this example, theblockchain user 522 connects to the network through a peer node 534.Before proceeding with any transactions, the peer node 534 retrieves theuser's enrollment and transaction certificates from the certificateauthority 536. In some cases, blockchain users must possess thesedigital certificates in order to transact on the permissioned blockchain524. Meanwhile, a user attempting to utilize chaincode may be requiredto verify their credentials on the traditional data source 532. Toconfirm the user's authorization, chaincode can use an out-of-bandconnection to this data through a traditional processing platform 538.

In some embodiments of the present disclosure, the blockchain herein maybe a permissionless blockchain. In contrast with permissionedblockchains which require permission to join, anyone can join apermissionless blockchain. For example, to join a permissionlessblockchain a user may create a personal address and begin interactingwith the network, by submitting transactions, and hence adding entriesto the ledger. Additionally, all parties have the choice of running anode on the system and employing the mining protocols to help verifytransactions.

FIG. 5C illustrates a process 550 of a transaction being processed by apermissionless blockchain 552 including a plurality of nodes 554. Asender 556 desires to send payment or some other form of value (e.g., adeed, medical records, a contract, a good, a service, or any other assetthat can be encapsulated in a digital record) to a recipient 558 via thepermissionless blockchain 552. In some embodiments, each of the senderdevice 556 and the recipient device 558 may have digital wallets(associated with the blockchain 552) that provide user interfacecontrols and a display of transaction parameters. In response, thetransaction is broadcast throughout the blockchain 552 to the nodes 554.

Depending on the blockchain's 552 network parameters the nodes verify560 the transaction based on rules (which may be pre-defined ordynamically allocated) established by the permissionless blockchain 552creators. For example, this may include verifying identities of theparties involved, etc. The transaction may be verified immediately, orit may be placed in a queue with other transactions and the nodes 554determine if the transactions are valid based on a set of network rules.

In structure 562, valid transactions are formed into a block and sealedwith a lock (hash). This process may be performed by mining nodes amongthe nodes 554. Mining nodes may utilize additional software specificallyfor mining and creating blocks for the permissionless blockchain 552.Each block may be identified by a hash (e.g., 256-bit number, etc.)created using an algorithm agreed upon by the network. Each block mayinclude a header, a pointer or reference to a hash of a previous block'sheader in the chain, and a group of valid transactions. The reference tothe previous block's hash is associated with the creation of the secureindependent chain of blocks.

Before blocks can be added to the blockchain, the blocks must bevalidated. Validation for the permissionless blockchain 552 may includea proof-of-work (PoW) which is a solution to a puzzle derived from theblock's header. Although not shown in the example of FIG. 5C, anotherprocess for validating a block is proof-of-stake. Unlike theproof-of-work, where the algorithm rewards miners who solve mathematicalproblems, with the proof of stake, a creator of a new block is chosen ina deterministic way, depending on its wealth, also defined as “stake.”Then, a similar proof is performed by the selected/chosen node.

With mining 564, nodes try to solve the block by making incrementalchanges to one variable until the solution satisfies a network-widetarget. This creates the PoW thereby ensuring correct answers. In otherwords, a potential solution must prove that computing resources weredrained in solving the problem. In some types of permissionlessblockchains, miners may be rewarded with value (e.g., coins, etc.) forcorrectly mining a block.

Here, the PoW process, alongside the chaining of blocks, makesmodifications of the blockchain extremely difficult, as an attacker mustmodify all subsequent blocks in order for the modifications of one blockto be accepted. Furthermore, as new blocks are mined, the difficulty ofmodifying a block increases, and the number of subsequent blocksincreases. With distribution 566, the successfully validated block isdistributed through the permissionless blockchain 552 and all nodes 554add the block to a majority chain which is the permissionlessblockchain's 552 auditable ledger. Furthermore, the value in thetransaction submitted by the sender 556 is deposited or otherwisetransferred to the digital wallet of the recipient device 558.

FIG. 6A illustrates a process 600 of a new block being added to adistributed ledger 620, according to example embodiments, and FIG. 6Billustrates contents of a new data block structure 630 for blockchain,according to example embodiments. The new data block 630 may containdocument linking data.

Referring to FIG. 6A, clients (not shown) may submit transactions toblockchain nodes 611, 612, and/or 613. Clients may be instructionsreceived from any source to enact activity on the blockchain 620. As anexample, clients may be applications that act on behalf of a requester,such as a device, person or entity to propose transactions for theblockchain. The plurality of blockchain peers (e.g., blockchain nodes611, 612, and 613) may maintain a state of the blockchain network and acopy of the distributed ledger 620. Different types of blockchainnodes/peers may be present in the blockchain network including endorsingpeers which simulate and endorse transactions proposed by clients andcommitting peers which verify endorsements, validate transactions, andcommit transactions to the distributed ledger 620. In this example, theblockchain nodes 611, 612, and 613 may perform the role of endorsernode, committer node, or both.

The distributed ledger 620 includes a blockchain which stores immutable,sequenced records in blocks, and a state database 624 (current worldstate) maintaining a current state of the blockchain 622. Onedistributed ledger 620 may exist per channel and each peer maintains itsown copy of the distributed ledger 620 for each channel of which theyare a member. The blockchain 622 is a transaction log, structured ashash-linked blocks where each block contains a sequence of Ntransactions. Blocks may include various components such as shown inFIG. 6B. The linking of the blocks (shown by arrows in FIG. 6A) may begenerated by adding a hash of a prior block's header within a blockheader of a current block. In this way, all transactions on theblockchain 622 are sequenced and cryptographically linked togetherpreventing tampering with blockchain data without breaking the hashlinks. Furthermore, because of the links, the latest block in theblockchain 622 represents every transaction that has come before it. Theblockchain 622 may be stored on a peer file system (local or attachedstorage), which supports an append-only blockchain workload.

The current state of the blockchain 622 and the distributed ledger 622may be stored in the state database 624. Here, the current state datarepresents the latest values for all keys ever included in the chaintransaction log of the blockchain 622. Chaincode invocations executetransactions against the current state in the state database 624. Tomake these chaincode interactions extremely efficient, the latest valuesof all keys are stored in the state database 624. The state database 624may include an indexed view into the transaction log of the blockchain622, it can therefore be regenerated from the chain at any time. Thestate database 624 may automatically get recovered (or generated ifneeded) upon peer startup, before transactions are accepted.

Endorsing nodes receive transactions from clients and endorse thetransaction based on simulated results. Endorsing nodes hold smartcontracts which simulate the transaction proposals. When an endorsingnode endorses a transaction, the endorsing node creates a transactionendorsement which is a signed response from the endorsing node to theclient application indicating the endorsement of the simulatedtransaction. The method of endorsing a transaction depends on anendorsement policy which may be specified within chaincode. An exampleof an endorsement policy is “the majority of endorsing peers mustendorse the transaction.” Different channels may have differentendorsement policies. Endorsed transactions are forward by the clientapplication to ordering service 610.

The ordering service 610 accepts endorsed transactions, orders them intoa block, and delivers the blocks to the committing peers. For example,the ordering service 610 may initiate a new block when a threshold oftransactions has been reached, a timer times out, or another condition.In the example of FIG. 6A, blockchain node 612 is a committing peer thathas received a new data new data block 630 for storage on blockchain620. The first block in the blockchain may be referred to as a genesisblock which includes information about the blockchain, its members, thedata stored therein, etc.

The ordering service 610 may be made up of a cluster of block generatorsor orderers. The ordering service 610 does not process transactions,smart contracts, or maintain the shared ledger. Rather, the orderingservice 610 may accept the endorsed transactions and specifies the orderin which those transactions are committed to the distributed ledger 620.The architecture of the blockchain network may be designed such that thespecific implementation of ‘ordering’ (e.g., Solo, Kafka, BFT, etc.)becomes a pluggable component.

Transactions are written to the distributed ledger 620 in a consistentorder. The order of transactions is established to ensure that theupdates to the state database 624 are valid when they are committed tothe network. Unlike a cryptocurrency blockchain system (e.g., Bitcoin,etc.) where ordering occurs through the solving of a cryptographicpuzzle, or mining, in this example the parties of the distributed ledger620 may choose the ordering mechanism that best suits that network.

When the ordering service 610 initializes a new data block 630, the newdata block 630 may be broadcast to committing peers (e.g., blockchainnodes 611, 612, and 613). In response, each committing peer validatesthe transaction within the new data block 630 by checking to make surethat the read set and the write set still match the current world statein the state database 624. Specifically, the committing peer candetermine whether the read data that existed when the endorserssimulated the transaction is identical to the current world state in thestate database 624. When the committing peer validates the transaction,the transaction is written to the blockchain 622 on the distributedledger 620, and the state database 624 is updated with the write datafrom the read-write set. If a transaction fails, that is, if thecommitting peer finds that the read-write set does not match the currentworld state in the state database 624, the transaction ordered into ablock may still be included in that block, but it may be marked asinvalid, and the state database 624 may not be updated.

Referring to FIG. 6B, a new data block 630 (also referred to as a datablock) that is stored on the blockchain 622 of the distributed ledger620 may include multiple data segments such as a block header 640, blockdata 650, and block metadata 660. It should be appreciated that thevarious depicted blocks and their contents, such as new data block 630and its contents. Shown in FIG. 6B are merely examples and are not meantto limit the scope of the example embodiments. The new data block 630may store transactional information of N transaction(s) (e.g., 1, 10,100, 500, 1000, 2000, 3000, etc.) within the block data 650. The newdata block 630 may also include a link to a previous block (e.g., on theblockchain 622 in FIG. 6A) within the block header 640. In particular,the block header 640 may include a hash of a previous block's header.The block header 640 may also include a unique block number, a hash ofthe block data 650 of the new data block 630, and the like. The blocknumber of the new data block 630 may be unique and assigned in variousorders, such as an incremental/sequential order starting from zero.

The block data 650 may store transactional information of eachtransaction that is recorded within the new data block 630. For example,the transaction data may include one or more of a type of thetransaction, a version, a timestamp, a channel ID of the distributedledger 620, a transaction ID, an epoch, a payload visibility, achaincode path (deploy tx), a chaincode name, a chaincode version, input(chaincode and functions), a client (creator) identify such as a publickey and certificate, a signature of the client, identities of endorsers,endorser signatures, a proposal hash, chaincode events, response status,namespace, a read set (list of key and version read by the transaction,etc.), a write set (list of key and value, etc.), a start key, an endkey, a list of keys, a Merkel tree query summary, and the like. Thetransaction data may be stored for each of the N transactions.

In some embodiments, the block data 650 may also store new data 662which adds additional information to the hash-linked chain of blocks inthe blockchain 622. The additional information includes one or more ofthe steps, features, processes and/or actions described or depictedherein. Accordingly, the new data 662 can be stored in an immutable logof blocks on the distributed ledger 620. Some of the benefits of storingsuch new data 662 are reflected in the various embodiments disclosed anddepicted herein. Although in FIG. 6B the new data 662 is depicted in theblock data 650 but may also be located in the block header 640 or theblock metadata 660. The new data 662 may include a document compositekey that is used for linking the documents within an organization.

The block metadata 660 may store multiple fields of metadata (e.g., as abyte array, etc.). Metadata fields may include signature on blockcreation, a reference to a last configuration block, a transactionfilter identifying valid and invalid transactions within the block, lastoffset persisted of an ordering service that ordered the block, and thelike. The signature, the last configuration block, and the blockgenerator or orderer metadata may be added by the ordering service 610.Meanwhile, a committer of the block (such as blockchain node 612) mayadd validity/invalidity information based on an endorsement policy,verification of read/write sets, and the like. The transaction filtermay include a byte array of a size equal to the number of transactionsin the block data 650 and a validation code identifying whether atransaction was valid/invalid.

FIG. 6C illustrates an embodiment of a blockchain 670 for digitalcontent in accordance with the embodiments described herein. The digitalcontent may include one or more files and associated information. Thefiles may include media, images, video, audio, text, links, graphics,animations, web pages, documents, or other forms of digital content. Theimmutable, append-only aspects of the blockchain serve as a safeguard toprotect the integrity, validity, and authenticity of the digitalcontent, making it suitable use in legal proceedings where admissibilityrules apply or other settings where evidence is taken in toconsideration or where the presentation and use of digital informationis otherwise of interest. In this case, the digital content may bereferred to as digital evidence.

The blockchain may be formed in various ways. In some embodiments, thedigital content may be included in and accessed from the blockchainitself. For example, each block of the blockchain may store a hash valueof reference information (e.g., header, value, etc.) along theassociated digital content. The hash value and associated digitalcontent may then be encrypted together. Thus, the digital content ofeach block may be accessed by decrypting each block in the blockchain,and the hash value of each block may be used as a basis to reference aprevious block. This may be illustrated as follows:

Block 1 Block 2 . . . Block N Hash Value 1 Hash Value 2 Hash Value NDigital Content 1 Digital Content 2 Digital Content N

In some embodiments, the digital content may be not included in theblockchain. For example, the blockchain may store the encrypted hashesof the content of each block without any of the digital content. Thedigital content may be stored in another storage area or memory addressin association with the hash value of the original file. The otherstorage area may be the same storage device used to store the blockchainor may be a different storage area or even a separate relationaldatabase. The digital content of each block may be referenced oraccessed by obtaining or querying the hash value of a block of interestand then looking up that has value in the storage area, which is storedin correspondence with the actual digital content. This operation may beperformed, for example, a database gatekeeper. This may be illustratedas follows:

Blockchain Storage Area Block 1 Hash Value Block 1 Hash Value . . .Content . . . . . . Block N Hash Value Block N Hash Value . . . Content

In the example embodiment of FIG. 6C, the blockchain 670 includes anumber of blocks 6781, 6782, . . . 678N cryptographically linked in anordered sequence, where N>1. The encryption used to link the blocks6781, 6782, . . . 678N may be any of a number of keyed or un-keyed Hashfunctions. In some embodiments, the blocks 6781, 6782, . . . 678N aresubject to a hash function which produces n-bit alphanumeric outputs(where n is 256 or another number) from inputs that are based oninformation in the blocks. Examples of such a hash function include, butare not limited to, a SHA-type (SHA stands for Secured Hash Algorithm)algorithm, Merkle-Damgard algorithm, HAIFA algorithm, Merkle-treealgorithm, nonce-based algorithm, and a non-collision-resistant PRFalgorithm. In other embodiments, the blocks 6781, 6782, . . . , 678N maybe cryptographically linked by a function that is different from a hashfunction. For purposes of illustration, the following description ismade with reference to a hash function, e.g., SHA-2.

Each of the blocks 6781, 6782, . . . , 678N in the blockchain includes aheader, a version of the file, and a value. The header and the value aredifferent for each block as a result of hashing in the blockchain. Insome embodiments, the value may be included in the header. As describedin greater detail below, the version of the file may be the originalfile or a different version of the original file.

The first block 6781 in the blockchain is referred to as the genesisblock and includes the header 6721, original file 6741, and an initialvalue 6761. The hashing scheme used for the genesis block, and indeed inall subsequent blocks, may vary. For example, all the information in thefirst block 6781 may be hashed together and at one time, or each or aportion of the information in the first block 6781 may be separatelyhashed and then a hash of the separately hashed portions may beperformed.

The header 6721 may include one or more initial parameters, which, forexample, may include a version number, timestamp, nonce, rootinformation, difficulty level, consensus protocol, duration, mediaformat, source, descriptive keywords, and/or other informationassociated with original file 6741 and/or the blockchain. The header6721 may be generated automatically (e.g., by blockchain networkmanaging software) or manually by a blockchain participant. Unlike theheader in other blocks 6782 to 678N in the blockchain, the header 6721in the genesis block does not reference a previous block, simply becausethere is no previous block.

The original file 6741 in the genesis block may be, for example, data ascaptured by a device with or without processing prior to its inclusionin the blockchain. The original file 6741 is received through theinterface of the system from the device, media source, or node. Theoriginal file 6741 is associated with metadata, which, for example, maybe generated by a user, the device, and/or the system processor, eithermanually or automatically. The metadata may be included in the firstblock 6781 in association with the original file 6741.

The value 6761 in the genesis block is an initial value generated basedon one or more unique attributes of the original file 6741. In someembodiments, the one or more unique attributes may include the hashvalue for the original file 6741, metadata for the original file 6741,and other information associated with the file. In one implementation,the initial value 6761 may be based on the following unique attributes:

-   -   1) SHA-2 computed hash value for the original file    -   2) originating device ID    -   3) starting timestamp for the original file    -   4) initial storage location of the original file    -   5) blockchain network member ID for software to currently        control the original file and associated metadata

The other blocks 6782 to 678N in the blockchain also have headers,files, and values. However, unlike header 6721 the first block, each ofthe headers 6722 to 672N in the other blocks includes the hash value ofan immediately preceding block. The hash value of the immediatelypreceding block may be just the hash of the header of the previous blockor may be the hash value of the entire previous block. By including thehash value of a preceding block in each of the remaining blocks, a tracecan be performed from the Nth block back to the genesis block (and theassociated original file) on a block-by-block basis, as indicated byarrows 680, to establish an auditable and immutable chain-of-custody.

Each of the header 6722 to 672N in the other blocks may also includeother information, e.g., version number, timestamp, nonce, rootinformation, difficulty level, consensus protocol, and/or otherparameters or information associated with the corresponding files and/orthe blockchain in general.

The files 6742 to 674N in the other blocks may be equal to the originalfile or may be a modified version of the original file in the genesisblock depending, for example, on the type of processing performed. Thetype of processing performed may vary from block to block. Theprocessing may involve, for example, any modification of a file in apreceding block, such as redacting information or otherwise changing thecontent of, taking information away from, or adding or appendinginformation to the files.

Additionally, or alternatively, the processing may involve merelycopying the file from a preceding block, changing a storage location ofthe file, analyzing the file from one or more preceding blocks, movingthe file from one storage or memory location to another, or performingaction relative to the file of the blockchain and/or its associatedmetadata. Processing which involves analyzing a file may include, forexample, appending, including, or otherwise associating variousanalytics, statistics, or other information associated with the file.

The values in each of the other blocks 6762 to 676N in the other blocksare unique values and are all different as a result of the processingperformed. For example, the value in any one block corresponds to anupdated version of the value in the previous block. The update isreflected in the hash of the block to which the value is assigned. Thevalues of the blocks therefore provide an indication of what processingwas performed in the blocks and also permit a tracing through theblockchain back to the original file. This tracking confirms thechain-of-custody of the file throughout the entire blockchain.

For example, consider the case where portions of the file in a previousblock are redacted, blocked out, or pixelated in order to protect theidentity of a person shown in the file. In this case, the blockincluding the redacted file may include metadata associated with theredacted file, e.g., how the redaction was performed, who performed theredaction, timestamps where the redaction(s) occurred, etc. The metadatamay be hashed to form the value. Because the metadata for the block isdifferent from the information that was hashed to form the value in theprevious block, the values are different from one another and may berecovered when decrypted.

In some embodiments, the value of a previous block may be updated (e.g.,a new hash value computed) to form the value of a current block when anyone or more of the following occurs. The new hash value may be computedby hashing all or a portion of the information noted below, in thisexample embodiment.

-   -   a) new SHA-2 computed hash value if the file has been processed        in any way (e.g., if the file was redacted, copied, altered,        accessed, or some other action was taken)    -   b) new storage location for the file    -   c) new metadata identified associated with the file    -   d) transfer of access or control of the file from one blockchain        participant to another blockchain participant

FIG. 6D illustrates an embodiment of a block which may represent thestructure of the blocks in the blockchain 690 in accordance with oneembodiment. The block, Blocki, includes a header 672 i, a file 674 i,and a value 676 i.

The header 672 i includes a hash value of a previous block Blocki−1 andadditional reference information, which, for example, may be any of thetypes of information (e.g., header information including references,characteristics, parameters, etc.) discussed herein. All blocksreference the hash of a previous block except, of course, the genesisblock. The hash value of the previous block may be just a hash of theheader in the previous block or a hash of all or a portion of theinformation in the previous block, including the file and metadata.

The file 674 i includes a plurality of data, such as Data 1, Data 2, . .. , Data N in sequence. The data are tagged with Metadata 1, Metadata 2,. . . , Metadata N which describe the content and/or characteristicsassociated with the data. For example, the metadata for each data mayinclude information to indicate a timestamp for the data, process thedata, keywords indicating the persons or other content depicted in thedata, and/or other features that may be helpful to establish thevalidity and content of the file as a whole, and particularly its use adigital evidence, for example, as described in connection with anembodiment discussed below. In addition to the metadata, each data maybe tagged with reference REF1, REF2, . . . , REFN to a previous data toprevent tampering, gaps in the file, and sequential reference throughthe file.

Once the metadata is assigned to the data (e.g., through a smartcontract), the metadata cannot be altered without the hash changing,which can easily be identified for invalidation. The metadata, thus,creates a data log of information that may be accessed for use byparticipants in the blockchain.

The value 676 i is a hash value or other value computed based on any ofthe types of information previously discussed. For example, for anygiven block Blocki, the value for that block may be updated to reflectthe processing that was performed for that block, e.g., new hash value,new storage location, new metadata for the associated file, transfer ofcontrol or access, identifier, or other action or information to beadded. Although the value in each block is shown to be separate from themetadata for the data of the file and header, the value may be based, inpart or whole, on this metadata in another embodiment.

Once the blockchain 670 is formed, at any point in time, the immutablechain-of-custody for the file may be obtained by querying the blockchainfor the transaction history of the values across the blocks. This query,or tracking procedure, may begin with decrypting the value of the blockthat is most currently included (e.g., the last (Nth) block), and thencontinuing to decrypt the value of the other blocks until the genesisblock is reached and the original file is recovered. The decryption mayinvolve decrypting the headers and files and associated metadata at eachblock, as well.

Decryption is performed based on the type of encryption that took placein each block. This may involve the use of private keys, public keys, ora public key-private key pair. For example, when asymmetric encryptionis used, blockchain participants or a processor in the network maygenerate a public key and private key pair using a predeterminedalgorithm. The public key and private key are associated with each otherthrough some mathematical relationship. The public key may bedistributed publicly to serve as an address to receive messages fromother users, e.g., an IP address or home address. The private key iskept secret and used to digitally sign messages sent to other blockchainparticipants. The signature is included in the message so that therecipient can verify using the public key of the sender. This way, therecipient can be sure that only the sender may have sent this message.

Generating a key pair may be analogous to creating an account on theblockchain, but without having to actually register anywhere. Also,every transaction that is executed on the blockchain is digitally signedby the sender using their private key. This signature ensures that onlythe owner of the account can track and process (if within the scope ofpermission determined by a smart contract) the file of the blockchain.

It is to be understood that although this disclosure includes a detaileddescription on cloud computing, implementation of the teachings recitedherein are not limited to a cloud computing environment. Rather,embodiments of the present disclosure are capable of being implementedin conjunction with any other type of computing environment now known orlater developed.

Cloud computing is a model of service delivery for enabling convenient,on-demand network access to a shared pool of configurable computingresources (e.g., networks, network bandwidth, servers, processing,memory, storage, applications, virtual machines, and services) that canbe rapidly provisioned and released with minimal management effort orinteraction with a provider of the service. This cloud model may includeat least five characteristics, at least three service models, and atleast four deployment models.

Characteristics are as follows:

On-demand self-service: a cloud consumer can unilaterally provisioncomputing capabilities, such as server time and network storage, asneeded automatically without requiring human interaction with theservice's provider.

Broad network access: capabilities are available over a network andaccessed through standard mechanisms that promote use by heterogeneousthin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

Resource pooling: the provider's computing resources are pooled to servemultiple consumers using a multi-tenant model, with different physicaland virtual resources dynamically assigned and reassigned according todemand. There is a sense of portion independence in that the consumergenerally has no control or knowledge over the exact portion of theprovided resources but may be able to specify portion at a higher levelof abstraction (e.g., country, state, or datacenter).

Rapid elasticity: capabilities can be rapidly and elasticallyprovisioned, in some cases automatically, to quickly scale out andrapidly released to quickly scale in. To the consumer, the capabilitiesavailable for provisioning often appear to be unlimited and can bepurchased in any quantity at any time.

Measured service: cloud systems automatically control and optimizeresource use by leveraging a metering capability at some level ofabstraction appropriate to the type of service (e.g., storage,processing, bandwidth, and active user accounts). Resource usage can bemonitored, controlled, and reported, providing transparency for both theprovider and consumer of the utilized service.

Service Models are as follows:

Software as a Service (SaaS): the capability provided to the consumer isto use the provider's applications running on a cloud infrastructure.The applications are accessible from various client devices through athin client interface such as a web browser (e.g., web-based e-mail).The consumer does not manage or control the underlying cloudinfrastructure including network, servers, operating systems, storage,or even individual application capabilities, with the possible exceptionof limited user-specific application configuration settings.

Platform as a Service (PaaS): the capability provided to the consumer isto deploy onto the cloud infrastructure consumer-created or acquiredapplications created using programming languages and tools supported bythe provider. The consumer does not manage or control the underlyingcloud infrastructure including networks, servers, operating systems, orstorage, but has control over the deployed applications and possiblyapplication hosting environment configurations.

Infrastructure as a Service (IaaS): the capability provided to theconsumer is to provision processing, storage, networks, and otherfundamental computing resources where the consumer is able to deploy andrun arbitrary software, which can include operating systems andapplications. The consumer does not manage or control the underlyingcloud infrastructure but has control over operating systems, storage,deployed applications, and possibly limited control of select networkingcomponents (e.g., host firewalls).

Deployment Models are as follows:

Private cloud: the cloud infrastructure is operated solely for anorganization. It may be managed by the organization or a third party andmay exist on-premises or off-premises.

Community cloud: the cloud infrastructure is shared by severalorganizations and supports a specific community that has shared concerns(e.g., mission, security requirements, policy, and complianceconsiderations). It may be managed by the organizations or a third partyand may exist on-premises or off-premises.

Public cloud: the cloud infrastructure is made available to the generalpublic or a large industry group and is owned by an organization sellingcloud services.

Hybrid cloud: the cloud infrastructure is a composition of two or moreclouds (private, community, or public) that remain unique entities butare bound together by standardized or proprietary technology thatenables data and application portability (e.g., cloud bursting forload-balancing between clouds).

A cloud computing environment is service oriented with a focus onstatelessness, low coupling, modularity, and semantic interoperability.At the heart of cloud computing is an infrastructure that includes anetwork of interconnected nodes.

FIG. 7A, illustrated is a cloud computing environment 710 is depicted.As shown, cloud computing environment 710 includes one or more cloudcomputing nodes 700 with which local computing devices used by cloudconsumers, such as, for example, personal digital assistant (PDA) orcellular telephone 700A, desktop computer 700B, laptop computer 700C,and/or automobile computer system 700N may communicate. Nodes 700 maycommunicate with one another. They may be grouped (not shown) physicallyor virtually, in one or more networks, such as Private, Community,Public, or Hybrid clouds as described hereinabove, or a combinationthereof.

This allows cloud computing environment 710 to offer infrastructure,platforms and/or software as services for which a cloud consumer doesnot need to maintain resources on a local computing device. It isunderstood that the types of computing devices 700A-N shown in FIG. 7Aare intended to be illustrative only and that computing nodes 700 andcloud computing environment 710 can communicate with any type ofcomputerized device over any type of network and/or network addressableconnection (e.g., using a web browser).

FIG. 7B, illustrated is a set of functional abstraction layers providedby cloud computing environment 710 (FIG. 7A) is shown. It should beunderstood in advance that the components, layers, and functions shownin FIG. 7B are intended to be illustrative only and embodiments of thedisclosure are not limited thereto. As depicted below, the followinglayers and corresponding functions are provided.

Hardware and software layer 715 includes hardware and softwarecomponents. Examples of hardware components include: mainframes 702;RISC (Reduced Instruction Set Computer) architecture based servers 704;servers 706; blade servers 708; storage devices 711; and networks andnetworking components 712. In some embodiments, software componentsinclude network application server software 714 and database software716.

Virtualization layer 720 provides an abstraction layer from which thefollowing examples of virtual entities may be provided: virtual servers722; virtual storage 724; virtual networks 726, including virtualprivate networks; virtual applications and operating systems 728; andvirtual clients 730.

In one example, management layer 740 may provide the functions describedbelow. Resource provisioning 742 provides dynamic procurement ofcomputing resources and other resources that are utilized to performtasks within the cloud computing environment. Metering and Pricing 744provide cost tracking as resources are utilized within the cloudcomputing environment, and billing or invoicing for consumption of theseresources. In one example, these resources may include applicationsoftware licenses. Security provides identity verification for cloudconsumers and tasks, as well as protection for data and other resources.User portal 746 provides access to the cloud computing environment forconsumers and system administrators. Service level management 748provides cloud computing resource allocation and management such thatrequired service levels are met. Service Level Agreement (SLA) planningand fulfillment 750 provide pre-arrangement for, and procurement of,cloud computing resources for which a future requirement is anticipatedin accordance with an SLA.

Workloads layer 760 provides examples of functionality for which thecloud computing environment may be utilized. Examples of workloads andfunctions which may be provided from this layer include: mapping andnavigation 762; software development and lifecycle management 764;virtual classroom education delivery 766; data analytics processing 768;transaction processing 770; and atomic committing 772.

FIG. 8 , illustrated is a high-level block diagram of an examplecomputer system 801 that may be used in implementing one or more of themethods, tools, and modules, and any related functions, described herein(e.g., using one or more processor circuits or computer processors ofthe computer), in accordance with embodiments of the present disclosure.In some embodiments, the major components of the computer system 801 maycomprise one or more CPUs 802, a memory subsystem 804, a terminalinterface 812, a storage interface 816, an I/O (Input/Output) deviceinterface 814, and a network interface 818, all of which may becommunicatively coupled, directly or indirectly, for inter-componentcommunication via a memory bus 803, an I/O bus 808, and an I/O businterface unit 810.

The computer system 801 may contain one or more general-purposeprogrammable central processing units (CPUs) 802A, 802B, 802C, and 802D,herein generically referred to as the CPU 802. In some embodiments, thecomputer system 801 may contain multiple processors typical of arelatively large system; however, in other embodiments the computersystem 801 may alternatively be a single CPU system. Each CPU 802 mayexecute instructions stored in the memory subsystem 804 and may includeone or more levels of on-board cache.

System memory 804 may include computer system readable media in the formof volatile memory, such as random-access memory (RAM) 822 or cachememory 824. Computer system 801 may further include otherremovable/non-removable, volatile/non-volatile computer system storagemedia. By way of example only, storage system 826 can be provided forreading from and writing to a non-removable, non-volatile magneticmedia, such as a “hard drive.” Although not shown, a magnetic disk drivefor reading from and writing to a removable, non-volatile magnetic disk(e.g., a “floppy disk”), or an optical disk drive for reading from orwriting to a removable, non-volatile optical disc such as a CD-ROM,DVD-ROM or other optical media can be provided. In addition, memory 804can include flash memory, e.g., a flash memory stick drive or a flashdrive. Memory devices can be connected to memory bus 803 by one or moredata media interfaces. The memory 804 may include at least one programproduct having a set (e.g., at least one) of program modules that areconfigured to carry out the functions of various embodiments.

One or more programs/utilities 828, each having at least one set ofprogram modules 830 may be stored in memory 804. The programs/utilities828 may include a hypervisor (also referred to as a virtual machinemonitor), one or more operating systems, one or more applicationprograms, other program modules, and program data. Each of the operatingsystems, one or more application programs, other program modules, andprogram data or some combination thereof, may include an implementationof a networking environment. Programs 828 and/or program modules 830generally perform the functions or methodologies of various embodiments.

Although the memory bus 803 is shown in FIG. 8 as a single bus structureproviding a direct communication path among the CPUs 802, the memorysubsystem 804, and the I/O bus interface 810, the memory bus 803 may, insome embodiments, include multiple different buses or communicationpaths, which may be arranged in any of various forms, such aspoint-to-point links in hierarchical, star or web configurations,multiple hierarchical buses, parallel and redundant paths, or any otherappropriate type of configuration. Furthermore, while the I/O businterface 810 and the I/O bus 808 are shown as single respective units,the computer system 801 may, in some embodiments, contain multiple I/Obus interface units 810, multiple I/O buses 808, or both. Further, whilemultiple I/O interface units are shown, which separate the I/O bus 808from various communications paths running to the various I/O devices, inother embodiments some or all of the I/O devices may be connecteddirectly to one or more system I/O buses.

In some embodiments, the computer system 801 may be a multi-usermainframe computer system, a single-user system, or a server computer orsimilar device that has little or no direct user interface, but receivesrequests from other computer systems (clients). Further, in someembodiments, the computer system 801 may be implemented as a desktopcomputer, portable computer, laptop or notebook computer, tabletcomputer, pocket computer, telephone, smartphone, network switches orrouters, or any other appropriate type of electronic device.

It is noted that FIG. 8 is intended to depict the representative majorcomponents of an exemplary computer system 801. In some embodiments,however, individual components may have greater or lesser complexitythan as represented in FIG. 8 , components other than or in addition tothose shown in FIG. 8 may be present, and the number, type, andconfiguration of such components may vary.

As discussed in more detail herein, it is contemplated that some or allof the operations of some of the embodiments of methods described hereinmay be performed in alternative orders or may not be performed at all;furthermore, multiple operations may occur at the same time or as aninternal part of a larger process.

The present disclosure may be a system, a method, and/or a computerprogram product at any possible technical detail level of integration.The computer program product may include a computer readable storagemedium (or media) having computer readable program instructions thereonfor causing a processor to carry out aspects of the present disclosure.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present disclosure may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, configuration data for integrated circuitry, oreither source code or object code written in any combination of one ormore programming languages, including an object oriented programminglanguage such as Smalltalk, C++, or the like, and procedural programminglanguages, such as the “C” programming language or similar programminglanguages. The computer readable program instructions may executeentirely on the user's computer, partly on the user's computer, as astand-alone software package, partly on the user's computer and partlyon a remote computer or entirely on the remote computer or server. Inthe latter scenario, the remote computer may be connected to the user'scomputer through any type of network, including a local area network(LAN) or a wide area network (WAN), or the connection may be made to anexternal computer (for example, through the Internet using an InternetService Provider). In some embodiments, electronic circuitry including,for example, programmable logic circuitry, field-programmable gatearrays (FPGA), or programmable logic arrays (PLA) may execute thecomputer readable program instructions by utilizing state information ofthe computer readable program instructions to personalize the electroniccircuitry, in order to perform aspects of the present disclosure.

Aspects of the present disclosure are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of thedisclosure. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a computer, or other programmable data processing apparatusto produce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks. These computerreadable program instructions may also be stored in a computer readablestorage medium that can direct a computer, a programmable dataprocessing apparatus, and/or other devices to function in a particularmanner, such that the computer readable storage medium havinginstructions stored therein comprises an article of manufactureincluding instructions which implement aspects of the function/actspecified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present disclosure. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the blocks may occur out of theorder noted in the Figures. For example, two blocks shown in successionmay, in fact, be accomplished as one step, executed concurrently,substantially concurrently, in a partially or wholly temporallyoverlapping manner, or the blocks may sometimes be executed in thereverse order, depending upon the functionality involved. It will alsobe noted that each block of the block diagrams and/or flowchartillustration, and combinations of blocks in the block diagrams and/orflowchart illustration, can be implemented by special purposehardware-based systems that perform the specified functions or acts orcarry out combinations of special purpose hardware and computerinstructions.

The descriptions of the various embodiments of the present disclosurehave been presented for purposes of illustration, but are not intendedto be exhaustive or limited to the embodiments disclosed. Manymodifications and variations will be apparent to those of ordinary skillin the art without departing from the scope and spirit of the describedembodiments. The terminology used herein was chosen to best explain theprinciples of the embodiments, the practical application or technicalimprovement over technologies found in the marketplace, or to enableothers of ordinary skill in the art to understand the embodimentsdisclosed herein.

Although the present disclosure has been described in terms of specificembodiments, it is anticipated that alterations and modification thereofwill become apparent to the skilled in the art. Therefore, it isintended that the following claims be interpreted as covering all suchalterations and modifications as fall within the true spirit and scopeof the disclosure.

The invention claimed is:
 1. A method comprising: splitting, by aprocessor, a transaction into sub-transactions based on a processingtime for each sub-transaction; sending, by the processor, eachsub-transaction to a different group of peers in a blockchain network,wherein each group has at least one peer from each essentialorganization in the blockchain network; wherein an essentialorganization is set by the blockchain network as an entity that mustparticipate in a validation of the transaction; receiving, by theprocessor, processed sub-transactions from the peers in the blockchainnetwork, wherein each sub-transaction contains an indication ofvalidation.
 2. The method of claim 1 further comprising: receiving avalidation determination for each sub-transaction; and invalidating thetransaction based on an invalidation of at least one sub-transactions,wherein all sub-transactions must be valid for the transaction to bevalid.
 3. The method of claim 2 further comprising: emitting an event tonotify a client application that the transaction has been immutablyappended to the blockchain network.
 4. The method of claim 2 furthercomprising, notifying a client application that the transaction wasinvalidated due to the invalidation of one or more sub-transactions. 5.The method of claim 1 further comprising: sending the processedsub-transactions to a block generator for the blockchain network;organizing, by the block generator, the processed sub-transactions intoblocks; and sending, by the block generator, the blocks to theblockchain network.
 6. The method of claim 5 further comprising:placing, by the block generator the processed sub-transactions into aqueue, and waiting, by the block generator, to organize until allprocessed sub-transactions for the transaction are received.
 7. Themethod of claim 1 further comprising: determining, by the blockchainnetwork, a validation state for each sub-transaction, wherein if onesub-transaction is invalidated, then the transaction is invalidated. 8.A system comprising: a processor; and a memory in communication with theprocessor, the memory containing program instructions that, whenexecuted by the processor, are configured to cause the processor toperform a method, the method comprising: split a transaction into two ormore sub-transactions; send each sub-transaction to a different group ofpeers in a blockchain network, wherein each group has at least one peerfrom each essential organization in the blockchain network; wherein anessential organization is set by the blockchain network as an entitythat must participate in a validation of the transaction; and receiveprocessed sub-transactions from the peers in the blockchain network. 9.The system of claim 8, the method further comprising: receiving avalidation determination for each sub-transaction; and invalidating thetransaction based on an invalidation of at least one sub-transactions,wherein all sub-transactions must be valid for the transaction to bevalid.
 10. The system of claim 9, the method further comprising:emitting an event to notify a client application that the transactionhas been immutably appended to the blockchain network.
 11. The system ofclaim 9, the method further comprising: notifying a client applicationthat the transaction was invalidated due to the invalidation of one ormore sub-transactions.
 12. The system of claim 8, the method furthercomprising: send the processed sub-transactions to a block generator forthe blockchain network; organize, by the block generator, the processedsub-transactions into blocks; and send, by the block generator, theblocks to the blockchain network.
 13. The system of claim 12, the methodfurther comprising: place, by the block generator the processedsub-transactions into a queue, and wait, by the block generator, toorganize until all processed sub-transactions for the transaction arereceived.
 14. The system of claim 8, the method further comprising:determine, by the blockchain network, a validation state for eachsub-transaction, wherein if one sub-transaction is invalidated, then thetransaction is invalidated.
 15. A computer program product comprising acomputer readable storage medium having program instructions embodiedtherewith, the program instructions executable with a processor, in anode of a blockchain network, to cause the processors to perform afunction, the function comprising: splitting, by the processor, atransaction into sub-transactions; sending, by the processor, eachsub-transaction to a different group of peers in a blockchain network,wherein each group has at least one peer from each essentialorganization in the blockchain network; wherein an essentialorganization is set by the blockchain network as an entity that mustparticipate in a validation of the transaction; and receiving, by theprocessor, processed sub-transactions from the peers in the blockchainnetwork.
 16. The computer program product of claim 15 furthercomprising: receiving a validation determination for eachsub-transaction; and invalidating the transaction based on invalidationof at least one sub-transactions, wherein all sub-transactions must bevalid for the transaction to be valid.
 17. The computer program productof claim 16 further comprising: emitting an event to notify a clientapplication that the transaction has been immutably appended to theblockchain network.
 18. The computer program product of claim 16 furthercomprising: notifying a client application that the transaction wasinvalidated due to the invalidation of one or more sub-transactions. 19.The computer program product of claim 15 further comprising: sending theprocessed sub-transactions to a block generator for the blockchainnetwork; organizing, by the block generator, the processedsub-transactions into blocks; and sending, by the block generator, theblocks to the blockchain network.
 20. The computer program product ofclaim 19 further comprising: placing, by the block generator theprocessed sub-transactions into a queue, and waiting, by the blockgenerator, to organize until all processed sub-transactions for thetransaction are received.